This is a game exported to HTML5 with 0.2.0i. I opened it in an iPhone 6S using Safari. It's using iOS 13.4.1.
The game seems to run fine. But the buttons are unresponsive. The menu button is rendered on top of the game. After wild tapping I was able to trigger an X button press. But I can't reproduce this reliably.
The HTML + JS files were uploaded directly to my web server here:
http://www.ceeu.de/picotest
I experienced the same problem when uploading the files to itch.io.
While we are here. I have a different problem when running on an older iPad Mini:
.gif)
A tiny icon of the game in the middle of the screen. Doesn't react to taps at all. Can't launch game.
This one uses iOS 9.3.5. A bit old so I didn't expect much anyway.
6 comments
One of the new features on 0.2.0 is moving sprites in the spritemap. This can be done in the map view with ctrl-x and ctrl-v. The map will be updated accordingly.
However, this won't undo properly. The map will revert but not the spritemap. See gif:
Tested in 0.2.0i
I fixed the crazy op laser,
added some bleeps and bloops for music
added a reset button after gameover
added sound effects
ammo count is 5,
dash now works in all directions depending on arrow key pressed
dash has a little bit of i frames
added a mean snowball thing that tracks you
its a little wonky as of now,
sometimes you will die out of nowhere. Sorry
How do I get to those spots that are like these pictures
I don't know how people get to these spots like is it in the PICO-8 item(not the website ver)?
Plz, let me know. Thx. :)
WARNING: LOUD
Not much to tell about this. It's just a simple PICO-8 diagnostic tool with alot of stat() commands.
This is my first game ever. I've only been using pico-8 for a few days. I have some games in the works that have more depth. This was just a stray idea to make the standard 'eat the small' game but with the character shrinking instead of growing. Hope you enjoy if you try it! <3
Every other file it automatically loads into the cart directory but it doesn't do that with the alpha demos and I can't find them anywhere in the game's folder. I can't find the carts online to download them
< START
<
< So I started getting into game development a little over a week ago, and I have alot of questions about this place and the fantasy consoles.
< To start out for context of what I've learned so far, I'm gonna link two videos. I've done most of the built in tutorials for game maker and
< the latest one was the "My first arena shooter tutorial". The first link is gonna be footage of what the finished tutorial project is supposed to
< look like a little about how it works, then the second clip is gonna be what I made and what I added and figured out (largely through brute
< trial and error) to do on my own. I have to record on my phone cuz I'm rocking a sweet 2011 macbook air and the appersoft recording
< software I'm used to using on other computers cuts the framerate down into a quarter of what it's supposed to be.
<
< [This is the tutorial version of the game] (https://drive.google.com/file/d/1hmiQXs0R1nHapy-cj6Iv2gzJ830rgd4M/view?usp=sharing)
<
< [This is my version] (https://drive.google.com/file/d/1olAcKUsyuc0jhraSa4P8du7Eqoui8o_C/view?usp=sharing)
<
< A few things I forgot to mention: those white circles spawn the enemies. Instead of placing an invisible object that spawns the enemies
< I made an object to spawn them that has hp and can be destroyed. What I meant by the cursor being weird is that I couldn't figure out how
< to make a proper persistent cursor that moves to the mouse point. Instead, in the step event (step event's in gamemaker are the equivalent
< of PICO's update function. They're code that's checked every frame. Dunno if step event is a common term so idk if this is common
< knowledge lmao) for my obj_player I wrote it so that he spawns the cursor image at the mousepoint every frame, then for the cursor, in it's
< create event (init() equalivent) I set it to have a starting cooldown count of 1, and then in the step event, it subtracts one point of cooldown
< every frame, and when the cooldown equals zero, it destroys itself. Definitely made the cursor looks weird. It's subtle but if you play close
< attention and move the mouse quickly you can actually see this occur. Anyway, that's general context for what I know so far about coding
< and game development. If you guys have any questions about the code and wanna look through it feel free to ask and I'll try to find the
< relevant code. I was planning on doing more with it, but since I got in way over my head with my own shit and didn't even consider waiting
< until I finished the tutorial, it kinda made me hate the project. Especially this one feature I tried to make where it would wait a second to
< respawn you upon death. Spent half a day trying to figure this shit out. Eventually, I got it to work by having the player drop an invisible
< object upon death, and having that trigger the restart the level 60 frames after it spawns. IDK wtf I did but when I loaded it up to record
< last night I found it not working anymore :(
<
< So, that out of the way, I first learned about PICO-8 through the Celeste PICO-8 easter egg. I literally just thought
< Pico-8 was the name of the Celeste prototype lmao. Jump 3 days ago, after finishing all the built in tutorials and I felt like I had kind of
< reached a dead end. I was just gonna continue working on that shooter. But over the course of that actual day, I learned a fuck ton. I
< learned how much overlapp there is between most beginner game engines (makes sense, I don't fully understand all of it but I know
< the general goal and changes of C# over C), then I found it.io by accident, and from there, I discovered PICO-8 and immediately thought
< "This would be great for game jams." Ended up spending half the day researching PICO-8 and a little bit learning voxatron, and I fell in love.
< I mean a game console make for an emulator made for the game console. That's fucking genius. Everything about how that whole aspect of
< of this is genius. It can run on anything easily, it's inherently amazing for debugging, and considering it's simplicity, it's much more beginner
< than most debuggers seem. I did the built in debugger tutorial for gamemaker and I still have no idea what the fuck happened during it.
< And the way that the console is the development software for the console, allowing the modulation of other people's games that this system was built for.
<
< Anyway, what general information should I know about Lexaloffle products, sites, and communities? Or useful information for people who just barely understands the basics of any of this?
<
< Where can I download the demo carts for both voxatron? I can play them but I can't find them anywhere in the game's folder so that I can edit them.
<
< How usable is PICO-8 for larger projects? Like I know you can package 16 carts together, but I'm assuming It's just a pack with each
< individual cart file rather than anything that stitches them together as one game, correct? I'd love to use PICO-8 as a way to make simpler
< games
< with much less overhead that actually has a reasonable amount of content. I like games you can sink alot of hours into so I'd rather make
< larger hobby projects. I'm not talking actually big games. I'm talking like an hour minimum (If it has good replay value) and four hours max.
< That's obviously alot more than I could currently handle, but I think in general that's a reasonable amount of playtime to expect to be able
< to produce. Like I would be very proud of a four hour game. And even further later on, how about using PICO-8 to build the majority of the < game and using gamemaker or something to stitch the levels together and further improve the game beyond what PICO-8 is capable of. I
< have no doubts about PICO's capacity for actual game design and mechanical complexity. It's main limitation is content size, other than
< that I feel like it's very capable for making a full game. It wouldn't even have to go
< against it's original design goal to achieve this. Leave amount of data that can be held in each cart to relatively the same, add an extra cart < type with a much harsher size restriction that's only to be used for assetts and code shared accross all levels, along with tools for stitching
< the levels together, and added features like a main menu screen. I feel like this would keep in with the spirit and intentions of PICO (and
< Vox but it's still in alpha) while allowing these softwares to be viable for full scale releases indie releases. It would turn PICO's relationship relationship to full games into what it's relationship already is with individual levels. Long run I'd love to like code the base of it and generate
< alot of the levels and of it in Pico,
< and then export it to something like gamemaker. I'm assuming once I start getting the hang of things and when I reach a high enough level < where this is even relevant, it shouldn't be too hard to figure out how to do that, correct?
<
< If you guys know any good Pico/voxatron games with a large amount of content similar to what I'm talking about I'd love it if you could send me an link
<
< What game dev resources/community websites and groups should I be aware of? All I'm really aware of is this and itch.io, both of which
< I learned about 2 days ago lol
<
< I think everything around the idea of these fantasy consoles is genius (I doubt that's a controversial opionion here lol) and I honestly think
< that it's kind of the future and there's alot of unique things you could do with it. Is the idea copyrighted? I know I have no immediate
< plans of doing something like that, but is it possible? Obviously I don't want to have someone just steal what these programs do, but
< just like the underlining concept. Zep has already proven that that it's a diverse concept with the differences between the two programs. I
< wanna know just about the base concept of a console made for an emulator made for that console, with the console being the
< the proprietary game development software, allowing you to play a game and immediately edit it. Especially with how popular open
< source is becoming, I honestly feel like this is kinda the future of game development. It just makes so much fucking sense.
<
< I know Voxatron is backwards compatible with PICO, what are the limitations of this and plans on expanding it? Is it possible planned at all
< to use that functionality to essentially treat both programs as one, treating vox like the 3D engine and PICO like the 2D engine? I feel like
< that would allow for a very versatile engine. Even moreso than either are on their own.
< Especially if it came with extra functionality to make this easier to do than expecting people to figure out how to do more complex features
< on their own. Like have a 2.5 D mode built specifically for this.
<
< That's about it. Thanks in advance!
<
< END
< SHUTDOWN
Instant 3D plus!
Instant 3D! was a random idea, quickly thrown together to see if it was possible. But after seeing the cool things people can do with it, I wanted to clean it up properly, and also present some of the internal functions more cleanly.
Making the 3D functions more accessible means:
- You can often get your game working correctly in 3D even if the Instant 3D "magic" doesn't work correctly, by calling the 3D spr/map functions directly with the right parameters.
- You can do things that the original Instant 3D can't do, like having objects that hover into the air.
I've added a little tutorial of converting a 2D game to 3D to illustrate how this works, at the bottom of this post.
Obviously this "snippet" is still very limited, compared to a general purpose 3D library say. You can't use it to create an FPS or a flight simulator. But I think it's a lot easier to use - start with a 2D game, drop it in, and fix up the bits that don't come out right. And you can still do some cool looking 3D stuff with it.
Here's the updated snippet:
-- instant 3d+!
do
-- parameters
p3d={
vanish={x=64,y=0}, -- vanishing pt
d=128, -- screen dist in pixels
near=1, -- near plane z
camyoff=32, -- added to cam y pos
camheight=32 -- camera height
}
-- save 2d versions
map2d,spr2d,sspr2d,pset2d,camera2d=map,spr,sspr,pset,camera
-- 3d camera position
local cam={x=0,y=0,z=0}
-- is 3d mode enabled?
is3d=false
-- helper functions
-- screen to camera space
local function s2c(x,y,z)
return x-cam.x,y-cam.y,z-cam.z
end
-- perspective projection
local function proj(x,y,z)
if -y>=p3d.near then
local scale=p3d.d/-y
return x*scale+p3d.vanish.x,-z*scale+p3d.vanish.y,scale
end
end
-- screen to projected
local function s2p(x,y,z)
local x,y,z=s2c(x,y,z)
return proj(x,y,z)
end
-- 3d drawing fns
function sspr3d(sx,sy,sw,sh,x,y,z,w,h,fx,fy)
w=w or sw
h=h or sh
local px,py,scale=s2p(x,y,z)
if(not scale)return
local pw,ph=w*scale,h*scale
-- sub pixel stuff
local x0,x1=flr(px),flr(px+pw)
local y0,y1=flr(py),flr(py+ph)
sspr2d(sx,sy,sw,sh,x0,y0,x1-x0,y1-y0,fx,fy)
end
spr3d=function(n,x,y,z,w,h,fx,fy)
if(not z)return
-- convert to equivalent sspr() call
w=(w or 1)*8
h=(h or 1)*8
local sx,sy=flr(n%16)*8,flr(n/16)*8
sspr3d(sx,sy,w,h,x,y,z,w,h,fx,fy)
end
function map3d(cx,cy,x,y,z,w,h,lyr)
if(not h)return
-- near/far corners
local fx,fy,fz=s2c(x,y,z)
local nx,ny,nz=s2c(x,y+h*8,z)
-- clip
ny=min(ny,-p3d.near)
if(fy>=ny)return
-- project
local npx,npy,nscale=proj(nx,ny,nz)
local fpx,fpy,fscale=proj(fx,fy,fz)
if npy<fpy then
local tx,ty,ts=npx,npy,nscale
npx,npy,nscale=fpx,fpy,fscale
fpx,fpy,fscale=tx,ty,ts
end
-- clamp
npy=min(npy,128)
fpy=max(fpy,0)
-- rasterise
local py=flr(npy)
while py>=fpy do
-- floor plane intercept
local g=(py-p3d.vanish.y)/p3d.d
local d=-nz/g
-- map coords
local mx,my=cx,(-fy-d)/8+cy
-- project to get left/right
local lpx,lpy,lscale=proj(nx,-d,nz)
local rpx,rpy,rscale=proj(nx+w*8,-d,nz)
-- delta x
local dx=w/(rpx-lpx)
-- sub-pixel correction
local l,r=flr(lpx+0.5)+1,flr(rpx+0.5)
mx+=(l-lpx)*dx
-- render
tline(l,py,r,py,mx,my,dx,0,lyr)
py-=1
end
end
function map3dupright(cx,cy,x,y,z,w,h,lyr)
if(not h)return
local px,py,scale=s2p(x,y,z)
if(not scale)return
local pw,ph=w*8*scale,h*8*scale
-- texture step
local dx,dy=w/pw,h/ph
local mx,my=cx+0.0625,cy+0.0625
-- sub pixel stuff
local x0,x1=flr(px),flr(px+pw)
local y0,y1=flr(py),flr(py+ph)
mx+=(x0-px)*dx
my+=(y0-py)*dy
if(x0>=x1 or y0>=y1)return
for y=y0,y1-1 do
tline(x0,y,x1,y,mx,my,dx,0,lyr)
my+=dy
end
end
function camera3d(x,y,z)
cam.x,cam.y,cam.z=x,y,z
end
-- "instant 3d" wrapper functions
local function icamera(x,y)
cam.x=(x or 0)+64
cam.y=(y or 0)+128+p3d.camyoff
cam.z=p3d.camheight
end
local function isspr(sx,sy,sw,sh,x,y,w,h,fx,fy)
z=h or sh
y+=z
sspr3d(sx,sy,sw,sh,x,y,z,w,h,fx,fy)
end
local function ispr(n,x,y,w,h,fx,fy)
z=(h or 1)*8
y+=z
spr3d(n,x,y,z,w,h,fx,fy)
end
local function imap(cx,cy,x,y,w,h,lyr)
cx=cx or 0
cy=cy or 0
x=x or 0
y=y or 0
w=w or 128
h=h or 64
map3d(cx,cy,x,y,0,w,h,lyr)
end
function go3d()
camera,sspr,spr,map=icamera,isspr,ispr,imap
camera2d()
is3d=true
end
function go2d()
map,spr,sspr,pset,camera=map2d,spr2d,sspr2d,pset2d,camera2d
is3d=false
end
-- defaults
icamera()
end
-- enable 3d mode
go3d()
menuitem(3,"3d",go3d)
menuitem(2,"2d",go2d) |
As before, to use it, just copy it into your 2D program. It should behave exactly the same.
There's one new feature, in that you can toggle between 2D and 3D in the Pico-8 menu.
You can also do it in code using
go2d() |
and
go3d() |
which might be useful for 2D title screens etc.
Taking it further
The basics are the same as before, but you can now - with a little bit of work - take your games a bit further by making use of explicit 2D and 3D commands, rather than leaving it up to the snippet to guess your intent.
To illustrate this, I made a little 2D cart to convert into 3D.
This is a simple little game where you're a bouncing ball that collects coins. It's not finished, but is enough to demonstrate the process. The game is already a little bit 3D in that the ball and coins also have a height, and objects can move in front and behind each other, so it has to sort their positions and draw them from back to front.
Dropping the snippet into this program has... mixed results.
As you can see, it's kind of 3D, but it has some issues:
- The ball doesn't always bounce straight up. In fact if you look closely it's actually staying on the ground and just bounces away and back again.
- The coins aren't raised up properly either.
- The metallic struts are flat on the ground, rather than standing up.
- Likewise the gratings on top are also flat on the ground.
- The 3 lives are displayed in the wrong place.
Obviously the snippet doesn't know exactly what we're trying to achieve, but fortunately we can help it out.
With a little bit of work we can make it look like this:
3D functions
We can fix up the ball using an explicit 3D function. The snippet provides explicit 3D functions spr3d, sspr3d and map3d. They have the same parameters as the standard functions, except there's a Z parameter immediately after the X and Y screen parameters.
They use a 3D coordinate system where:
- The X axis is to the right
- The Y axis is out of the screen (towards you)
- The Z axis is up
This keeps X and Y consistent with the "Instant 3D" logic, where instead of moving up the screen as Y decreases, objects move away from you. The new Z parameter allows us to also specify the height.
The ball drawing code looks like this:
elseif thing.typ=="player" then
shadowcols()
sspr(0,32,
8,8,
thing.x-4,thing.y-1,
8,4)
pal()
spr(64+thing.frame%9,
thing.x-4,
thing.y-thing.height-8)
end |
The sspr() call draws the shadow, which looks correct already, so it doesn't need to change.
The spr() call draws the ball, based on the thing.x,-.y and -.height variables. The game stores the position of bottom center of the ball, so it has to subtract 4 and 8 to get the top left corner for spr().
We can change it to an explicit 3D call as follows:
spr3d(64+thing.frame%9,
thing.x-4,
thing.y,
thing.height+8) |
We're still specifying the top left corner, but now it's in 3D.
The coin code is similar:
if thing.typ=="coin" then
shadowcols()
sspr(0,40,
8,8,
thing.x-4,thing.y-1,
8,4)
pal()
spr(80,
thing.x-4,thing.y-thing.height-8) |
Once again we change the spr call to an spr3d:
spr3d(80,
thing.x-4,
thing.y,
thing.height+8) |
With 3D positions supplied, the ball and coins now bounce/float above the ground properly.
Upright maps
Next we can address the red metal structs. Currently they are lying flat on the ground instead of standing up straight.
The "instant 3D" snippet assumes everything drawn with "spr"/"sspr" is upright, and everything drawn with "map" is flat on the ground. However the struts are drawn using map(), so that they can be composed of multiple sprites.
So we need to tell the game to draw them upright.
map3d won't help in this case. We can use it to draw them higher up, but they will still be lying flat, not standing upright. So to help with this the snippet provides an alternative "map3dupright" function.
The strut drawing code is:
elseif thing.typ=="strut" then
map(127,0,
thing.x,thing.y-40,
1,5) |
We can change the map call to a map3dupright like this:
map3dupright(127,0,
thing.x,
thing.y,
40,
1,5) |
Once again it has the same parameters as "map", except there's a Z parameter immediately after the X and Y.
The struts are 40 pixels high, so we set the Z (i.e. the height) to 40, to specify the top left corner position.
With this in place, the struts now stand upright.
3D parameters
Now that objects are above the ground they often disappear above the top of the screen.
This is due to the camera height, and the "vanishing point" of the 3D projection, which is currently set to the top of the screen.
We can easily fix this by changing the 3D parameters.
The default parameters are in the snippet:
-- parameters
p3d={
vanish={x=64,y=0}, -- vanishing pt
d=128, -- screen dist in pixels
near=1, -- near plane z
camyoff=32, -- added to cam y pos
camheight=32 -- camera height
} |
We can move the vanishing point into the center of the screen by adding a line to the _init function:
p3d.vanish.y=64 |
Moving the vanishing point is like rotating the camera upwards slightly. Now we can easily see everything.
In fact we can even move the camera down a little and nearer to the ball:
p3d.camheight=20 p3d.camyoff=20 |
3D map coordinates
Now we'll fix the metal grates. These are supposed to sit on top of the struts.
The grates are rendered as a single map, much like the floor. We need to tell the game to draw that map above the ground.
This time map3d is the correct function to use.
The existing code looks like this.
-- roof map map(32,0,0,-40,16,64) |
The 3D code is quite similar:
-- roof map map3d(32,0,0,0,40,16,64) |
Once again we have a new Z parameter after the X and Y, which we set to 40 to move it up into the air.
In the 2D version the grates are drawn last, as because they are above everything. However in the 3D version they actually need to be drawn before the ball, coins and struts to get the correct ordering.
So the line should be moved up immediately after the "map" call that draws the floor.
2D drawing
The last thing to fix is the lives display. Lives are displayed as 3 balls, but they are drawn in the wrong place, because the "instant 3D" logic is trying to position them in 3D.
In this case we really just want to draw them in 2D.
Fortunately the snippet saves the original 2D functions as "spr2d", "sspr2d" and "map2d", so we can call them directly if we need to.
The life drawing code looks like this:
-- overlay
camera()
fancyprint("lives",4,4,12)
for i=1,player.lives do
spr(64,25+(i-1)*9,2)
end |
Simply change the "spr" to "spr2d" and we're done.
2D/3D code
Adding the various 3D calls makes the game look correct in 3D now. But if you switch it back to 2D (via the pause menu) it now looks broken.
One solution is to simply remove the "menuitem" calls from the snippet and disable mode switching. This is perfectly valid if the game is only supposed to be 3D.
But if you really do want the 2D option, it is still possible. The snippet includes a variable "is3d" which is set to true in 3D mode. Before calling any 3D function, check it to ensure you are actually in 3D mode. If not, perform the original 2D call instead. For example:
if is3d then spr3d(64+thing.frame%9, thing.x-4, thing.y, thing.height+8) else spr(64+thing.frame%9, thing.x-4, thing.y-thing.height-8) end |
Here's the final cart with 2D and 3D mode support.
Other bits
That's the gist of how to use it. There are a couple of functions I've missed, like camera3d (sets the 3D camera position explicitly, rather than inferring it from the 2D position and height/y-offset parameters), and a pset3d/pset2d which should do what you'd expect.
Feel free to throw me any questions you have.
-Mot
** Update 1: Fix spr() when drawing larger than 1x1 sprites
Hey, everyone! This is a little game I developed in August of last year. I'm a beginner hobbyist game developer, and love the idea of creating games for a limited platform. This is my first completed creation for PICO-8, had a lot of fun building it.
In Cat Catcher 0 you must catch stray cats that are running rampant around the town and causing mischief. Try not to let any of them escape!
Please share your impressions and opinions!
 (1).gif)
I want more information on filling chests ith items(sword,armour,bow) randomly.
I wish to do this with a table called items made up on tables for each item like this
function chest_setup()
(here the tables of each item)
end
function bow_setup()
b={}
b.range=3
b.arrows=5
end |
This with all the items
How would I do this?
Any help will be mostly appreciated
What does it mean when I get this symbol?
It seems to me to be an Unknown Error sign because every time I get it I don't know why. And all I know is its an Error sign. So I'm assuming its an Unknown Error sign. The only time I get it often is When I'm playing this one game I forgot the name to and who its made by.
Well, I'm trying to make a rhythm game and I want the enemies to change sprite (To look as they were dancing) and attack following the tempo of the current song. It's my first game and I don't know too much about code or how pico-8 works. I tried to make a T variable that add one to its current value each frame and to use a the "%" operator to sync the frame counter to the beat but it's hard to do it that way and I feel like it doesn't sync too well. Can anyone help me to code it?
This is a tribute/demake to the original, oldschool Commander Keen games! Still very much a work in progress. The first level is done. Updated 12/30/2020
A River Rumble Arena Shooter for 1-4 players
Dive into rivers to rush downstream and get the jump on your opponents!
[Controls]
Arrow keys to move
Z - Shoot
X - Drop bomb
I was wondering even though we can't make online games(Or I think we can't), Can we at least make games with battle royale and making the opponents bots? And I mean by battle royale I mean like Fortnite if you play Fortnite
// Promo video by m7kenji with music by Kyohei Fujita
Shibuya Pixel Art 2020 is accepting submissions until the end of June, and this year there is a new category for 128x128 games! Lexaloffle is sponsoring the game category with a prize (a Picade Cabinet), and by offering a limited number of PICO-8 licenses to participants.
Similar to a game jam, entries should be based on one or more of the following themes: Shibuya, AI, Humanity, Game and/or Landscape. Unlike typical game jams, existing work can be adapted or reused, as long as it did not win a previous contest. You can find previous winning entries for 2018 and 2019.
To enter: simply post the image on twitter or instagram with the hashtag: #shibuyapixelart2020. It is possible to submit more than one entry. For game submissions, post an image of the titlescreen along with a link to the playable game (this BBS / itch.io etc). I suppose for images you'd also want to post a link to the original non-compressed version if needed. Also note that previous years' selections also included gifs/mp4s that also work as still images.
Apart from a Grand Prize (300k yen + a Wacom tablet), there are also 4 special category awards for: Limited Pixel Art, Analogue Pixel Art, Beyond Pixel Art and Pixel Art Game. Winning entries are announced in early August, with an exhibition and awards ceremony in September. But you don't need to be in Japan to enter!
For more information, and to read the full terms & conditions of entries, please visit the official contest homepage: https://pixel-art.jp/ (there is an automatic English translation button near the top of the main content).
UPDATE: I'm not sure if there are restrictions on team projects yet, but will update this thread with any news.
SHIBUYA GIRLS by @yacoyon 2019
生まれ変わる町 by @m7kenji 2019
Shards of Destiny
A lovingly crafted, nostalgic pico-size RPG adventure
Overview
This is my second game jam game, and second Pico-8 game (I'll get around to publishing the first one at some point). It was a frantic development in early mornings and late evenings for four days, but I got it into a more or less playable shape. Then I worked on it for about one month, making it less bare-bones and more of a game. It's a very tiny open-world RPG with light puzzles, dungeons and a very vague and generic (on purpose) back story. It basically combines the look of early Ultimas with my take on very light RPG/adventure gameplay. Pico-8 is basically the perfect platform for this type of game, and I've already got ideas for a sequel :)
Dev log
12.06.2020
Ok, after some more playtesting I decided that done is done. The game can be played from start to finish, all features I wanted are in and there don't seem to be any deal-breaking bugs. There will probably be minor updates here and there as I find embarrassing stuff that should've been fixed ages ago, but nothing major is coming. So thus I completed my first RPG ever. Tiny and simplistic, but still. Time to pat myself on the back and move on.
09.06.2020
So I'll call it beta now. I've added a new special item, rearranged the location of all items, added the most powerful sword and shield and changed victory conditions, which I will not spoil here, but I hope that the in-game clues point to it clearly enough. I also tweaked the final battle somehow, but I'm still not 100% sure whether it's good enough, I'll probably tinker with it some more. I've also added a small tribute to one of my favourite game music composers, which you can see when you finish the game (with the good ending).
28.05.2020
I realised that what I uploaded yesterday was a buggy mess and I had to correct some things. Hence, version number with an ominous "b" at the end. Also, I added a level up message thanks to a helpful comment by @jeb
27.05.2020
We're still in alpha and I'm adding features left and right, as the pico-ness of Pico-8 allows me. Here's the gist:
- Added separate dungeon music
- Improved enemy 'AI'. While they are still (intentionally) dumb as rocks, they now have the ability to properly surround you if there are no obstacles in their way.
- Added two magic items: a healing ring and a wand that will severely hurt all monsters within one space of the hero. You have to dig around to find them.
- Added nicer win messages
- Improved some locations to prevent the "invisible wall" effect
- Added more dialogue, replaced some useless lines like "please help us" with clues regarding new items
- Added "tough" versions of monsters to some dungeons, they are palette-swapped versions of normal monsters (don't judge, I'm already at the sprite limit, and I'm using the entire map) with increased stats
The roadmap still includes several items, such as better ending, some simple special abilities for monsters, more weapons and shields and whatever I can fit in the token limit (it's great that the limit is there, it's a clear boundary where you simply have to stop).
21.05.2020
Today I released a new version of the game. Let's call it 0.1.0 alpha or whatever greek letter is appropriate. This version contains several improvements, most notably:
- No more obvious crippling bugs, that is you can't load a game when there's nothing to load, to crash and burn, and you can't fall off the edge of the world because I forgot one mountain tile.
- Improved music which now fits on less patterns internally (invisible), and added game over music (definitely audible).
- Raised the cost of purchasable items and decreased gold left by monsters. Otherwise the gold was pretty much pointless. It kind of still is, but I'm working on it.
- Added another item which is not required to win the game, but you can get several nice finds using it, if you know where to look!
- Added some semi-hidden extras for the intrepid explorers of the pico-kingdom
There's still a lot of work, but that's what I call progress!
19.05.2020
The work is progressing as fast as my almost-one-year-old allows me to :) Today I focused on the music, I wanted to extend the loop a bit, and also I intend to add some dungeon music and jingles for game over and win screens. By the way, a better win screen would be nice as well, but one thing at a time here...
17.05.2020
I am in the process of bringing the jam version, which was incredibly rushed and buggy, to a more polished state. I started by removing two breaking bugs (one was the ability to load game when no saved game was available, and the second was a spot where you could go outside the end of the world and crash the game) and cleaning the code a bit, the next step was to add a nicer game over graphics (I have quite a bit of room left in the sprite section, so why not use it). Now I am reworking the balance of the monsters and the "economy". As is, it's all over the place, it's a miracle that it even kind of works. But the thing is that gold is irrelevant, because everything is super cheap right from the start, and the monsters don't feel that powerful. They are purposefully very simplistic, but perhaps too simplistic? I might end up sprinkling some special abilities here and there, not too much in order not to break the simplicity of the game, but I used just above half of the tokens - might as well add a little bit more content. Speaking of content, I also added a pickaxe which you will be able to use to dig in some special rock tiles, and maybe find some goodies (which are very limited as they are now). I'll post it when I test it reasonably thoroughly.
Previous versions - for reference
Version 0.2.0
Version 0.1.3b
Version 0.1.0
Version 0.0.1
My first Pico-8 game! Super simple, excited to learn more about Pico. Originally I wanted to make more of a bullet hell game, but with my limited knowledge and my goal of finishing in a single night, that wasn't feasible. So, I cut back on scope and leaned more into a weirder, shorter, more experimental game.
Programming, Art, and Music by me.
Use the Arrow Keys to try and find love. X and C don't have a function in this game.
Banana Chase is a fast-paced arcade maze game or 'collect'em up' where you are Monty, a very hungry monkey. Eat your way through 28 levels of fruit-based action as you uncover the mystery of the magical forest.
•Chain together combos of fruit to get the most points.
•Don't eat mushrooms!
•Two difficulties, Easy and Hard.
•Five different types of fruit to eat.
•Three different enemies, learn the tricks and tactics to circumvent them.
•28 levels, explore the magic forest and complete the wizard's quest.
•Complete the game in the fastest time.
X - Advance chat, hide UI
Z - Level skip
This started off life as a very simple demo, and my first attempt at making a Pico-8 game. I didn't like leaving it unfinished, so I've been steadily adding to it on and off over the last few months.
I really admire speedrunning, so I tried to make this game as speedrun friendly as possible.
I didn't really have any particular inspiration in mind when making the game. I teach programming in schools with Scratch and it was kind of based on one of the games I make in that. It ended up kind of Pac-Man-esque, in that you collect things and are in a kind of maze, but that's a bit of a stretch.
|
[0x0] |
Old Versions
Version History
v3.01 - Fixed an issue with best times not being carried between games, added cartdata functionality to save best times between sessions.
v3.0 - It's four years later and I'm still fiddling around with this: Added a tutorial to explain how the hell scoring works; a sprite outline effect to make objects stand out better; particle effects because particle effects. This was all made possible by streamlining much of the code, no more tables as containers for variables. Probably some other changes I forgot about.
v2.1 - After some great feedback (thanks @jeb!) I've made some changes I was kicking myself for not thinking of.
•Added a walking animation for the monkey
•Added a third difficulty, so now there's Easy - 125pts per level, Normal - 250pts and Hard - 500pts. You can easily get through easy (pun intended) in under fifteen minutes.
•Made a bunch of minor adjustments to map layouts, there shouldn't be such a big difficulty spike in the mid-game now.
•Fruit should no longer appear directly adjacent to or on top of the monkey. Less broken streaks!